home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Easy Personal Web Page
/
Easy Personal Web Page.iso
/
EMAIL
/
PEGASUS
/
MERCURY
/
IMPORTAN.T!!
< prev
next >
Wrap
Text File
|
1993-11-26
|
5KB
|
102 lines
┌────────────────────────────────────────────────┐
│ Form number problems │
└────────────────────────────────────────────────┘
At some stage during the development life of CLIB.NLM, Novell made
arbitrary changes to some of the NetWare API calls which access and
create jobs in NetWare queues. For no apparent reason, and without
warning to developers, they altered some of the routines so that they
swapped the order of bytes in the "form number" field of the job
record. Older versions of Mercury required the use of confusing JOB
statements in MERCURY.INI to correct the CLIB changes, but Mercury
1.11 includes internal logic to detect offending CLIB versions and
correct the values automatically. JOB numbers needed by older
versions of Mercury are therefore obsolete and possibly a nuisance,
so Mercury 1.11 ignores them. Furthermore, if you choose to use
Mercury's file-based spooler submission mechanism, the problem
becomes completely irrelevant.
It is still imaginable, however, that you may encounter a version of
CLIB where Mercury cannot make the appropriate adjustments to the
Form numbers, so the ability to remap the form numbers Mercury uses
is still implemented using FORM statements in MERCURY.INI. The most
obvious symptom that you might need to use these statements is the
appearance of jobs in the mailqueue with strange job numbers like
25856 or 28160. You can tell at a glance whether this problem is
occurring on your system by running PCONSOLE and examining the mail
queue. All jobs in the list should be either form type 101 or form
type 110. If you see other form numbers then you have the problem.
NOTE: PCONSOLE only shows the first four digits of the form number in
the queue list - to see the whole form number, you must select a job
and press <Enter> to see its full description.
The form numbers Mercury uses when scanning for and creating jobs in
the NetWare mail queues can be adjusted on a module-by-module basis
using FORM statements in the module's definition section in
MERCURY.INI. The form statements take the following forms:
FORM1: Defines the value the module should use when SCANNING for
jobs to service. Mercury.NLM scans for jobs of type 101,
MercuryC.NLM scans for jobs of type 110 and MercuryS.NLM
does no scanning at all.
FORM2: Defines the form number the module should use when CREATING
a job to be processed by MercuryC.NLM - that is, outgoing
mail. Only Mercury.NLM uses this value, which defaults to
110.
FORM3: Defines the form number the module should use when CREATING
a job which should be examined by Mercury.NLM (that is, any
mail which is definitely for local delivery, or where the
local/nonlocal status is unknown). The usual value for this
field is 101. MercuryS.NLM uses this value to create jobs
for any incoming mail. Mercury.NLM and MercuryC.NLM use this
value when creating delivery failure and other notifications,
and the mail server always creates jobs using this value.
Using form definitions is fairly straightforward; find the incorrect
job number which is appearing in the mail jobs in the queue, and
determine the source of the job in the queue using the information
in the sections above, and by following a job through its life in
the queue using PCONSOLE. Create FORMx entries as appropriate in the
offending module's section in MERCURY.INI using the incorrect number
as the value.
Examples:
* Mercury.NLM is accepting mail from PMail with job type 101, but
is creating outgoing mail with the job type 28160, and is creating
delivery failure notifications with the job type 25856
-- The job type Mercury.NLM scans for is OK, so there's no need for
-- a FORM1 field. The outgoing mail has the wrong number, so we need
-- to add a FORM2 field, and because delivery failures are local
-- mail we deduce that we also need a FORM3 field. The following
-- lines need to be added to MERCURY.INI in the [MERCURY] section:
--
-- FORM2: 28160
-- FORM3: 25856
* MercuryC.NLM is processing outgoing mail without any trouble, but
delivery failure notifications are going into the mail queue with
the form number 25856; as well, MercuryS.NLM is creating all
incoming mail with form number 25856.
-- Both NLMs are creating local mail, so the FORM3 field in each
-- NLM's section in MERCURY.INI needs to be adjusted. The following
-- line would be added into each NLM's section:
--
-- FORM3: 25856
I stress that it should not in general be necessary to use this form
remapping capability: Mercury 1.11 has been tested with NetWare 3.11
(using several versions of CLIB.NLM), NetWare 3.12 and NetWare 4.01
and its internal correction logic has been found to work correctly on
all these versions. This information is provided only as a hedge
against future changes by Novell.
If you encounter form-number problems with Mercury 1.11 please contact
the author by Internet e-mail to david@pmail.gen.nz.